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1. Introduction 


Providers of Internet content and other services may wish to customize those services based on 
the geographic location of the user of the service. This is often done using the source IP address 
used to contact the service. Also, infrastructure and other services might wish to publish the 
locale of their services. [RFC8805] defines geofeed, a syntax to associate geographic locales with 
IP addresses, but it does not specify how to find the relevant geofeed data given an IP address. 


This document specifies how to augment the Routing Policy Specification Language (RPSL) 
[RFC2725] inetnum: class to refer specifically to geofeed data CSV files and how to prudently use 
them. In all places inetnum: is used, inet6num: should also be assumed [RFC4012]. 


The reader may find [INETNUM] and [INET6NUM] informative, and certainly more verbose, 
descriptions of the inetnum: database classes. 


An optional utterly awesome but slightly complex means for authenticating geofeed data is also 
defined. 
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1.1. Requirements Language 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 
NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to 
be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in 
all capitals, as shown here. 


2. Geofeed Files 


Geofeed files are described in [RFC8805]. They provide a facility for an IP address resource 
"owner" to associate those IP addresses to geographic locales. 


Content providers and other parties who wish to locate an IP address to a geographic locale need 
to find the relevant geofeed data. In Section 3, this document specifies how to find the relevant 
geofeed [RFC8805] file given an IP address. 


Geofeed data for large providers with significant horizontal scale and high granularity can be 
quite large. The size of a file can be even larger if an unsigned geofeed file combines data for 
many prefixes, if dual IPv4/IPv6 spaces are represented, etc. 


Geofeed data do have privacy considerations (see Section 6); this process makes bulk access to 
those data easier. 


This document also suggests an optional signature to strongly authenticate the data in the 
geofeed files. 


3. inetnum: Class 


The original RPSL specifications starting with [RIPE81], [RIPE181], and a trail of subsequent 
documents were written by the RIPE community. The IETF standardized RPSL in [RFC2622] and 
[RFC4012]. Since then, it has been modified and extensively enhanced in the Regional Internet 
Registry (RIR) community, mostly by RIPE [RIPE-DB]. Currently, change control effectively lies in 
the operator community. 


The RPSL, and [RFC2725] and [RFC4012] used by the Regional Internet Registries (RIRs), specify 
the inetnum: database class. Each of these objects describes an IP address range and its 
attributes. The inetnum: objects form a hierarchy ordered on the address space. 


Ideally, RPSL would be augmented to define a new RPSL geofeed: attribute in the inetnum: class. 
Until such time, this document defines the syntax of a Geofeed remarks: attribute, which 
contains an HTTPS URL of a geofeed file. The format of the inetnum: geofeed remarks: attribute 
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MUST be as in this example, "remarks: Geofeed ", where the token "Geofeed " MUST be case 
sensitive, followed by a URL that will vary, but it MUST refer only to a single geofeed [RFC8805] 
file. 


inetnum: 192.0.2.0/24 # example 
remarks: Geofeed https://example.com/geofeed.csv 


While we leave global agreement of RPSL modification to the relevant parties, we specify that a 
proper geofeed: attribute in the inetnum: class MUST be "geofeed:" and MUST be followed by a 
single URL that will vary, but it MUST refer only to a single geofeed [RFC8805] file. 


inetnum: 192.0.2.0/24 # example 
geofeed: https://example.com/geofeed.csv 


Registries MAY, for the interim, provide a mix of the remarks: attribute form and the geofeed: 
attribute form. 


The URL uses HTTPS, so the WebPKI provides authentication, integrity, and confidentiality for 
the fetched geofeed file. However, the WebPKI can not provide authentication of IP address space 
assignment. In contrast, the RPKI (see [RFC6481]) can be used to authenticate IP space 
assignment; see optional authentication in Section 4. 


Until all producers of inetnum: objects, i.e., the RIRs, state that they have migrated to supporting 
a geofeed: attribute, consumers looking at inetnum: objects to find geofeed URLs MUST be able to 
consume both the remarks: and geofeed: forms. The migration not only implies that the RIRs 
support the geofeed: attribute, but that all registrants have migrated any inetnum: objects from 
remarks: to geofeed: attributes. 


Any particular inetnum: object MUST have, at most, one geofeed reference, whether a remarks: 
or a proper geofeed: attribute when it is implemented. If there is more than one, all are ignored. 


If a geofeed CSV file describes multiple disjoint ranges of IP address space, there are likely to be 
geofeed references from multiple inetnum: objects. Files with geofeed references from multiple 
inetnum: objects are not compatible with the signing procedure in Section 4. 


When geofeed references are provided by multiple inetnum: objects that have identical address 
ranges, then the geofeed reference on the inetnum: with the most recent last-modified: attribute 
SHOULD be preferred. 


As inetnum: objects form a hierarchy, geofeed references SHOULD be at the lowest applicable 
inetnum: object covering the relevant address ranges in the referenced geofeed file. When 
fetching, the most specific inetnum: object with a geofeed reference MUST be used. 


It is significant that geofeed data may have finer granularity than the inetnum: that refers to 
them. For example, an INETNUM object for an address range P could refer to a geofeed file in 
which P has been subdivided into one or more longer prefixes. 
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Currently, the registry data published by ARIN are not the same RPSL as that of the other 
registries (see [RFC7485] for a survey of the WHOIS Tower of Babel); therefore, when fetching 
from ARIN via FTP [RFC0959], WHOIS [RFC3912], the Registration Data Access Protocol (RDAP) 
[RFC9082], etc., the "NetRange" attribute/key MUST be treated as "inetnum", and the "Comment" 
attribute MUST be treated as "remarks". 


4. Authenticating Geofeed Data 


The question arises whether a particular geofeed [RFC8805] data set is valid, i.e., is authorized by 
the "owner" of the IP address space and is authoritative in some sense. The inetnum: that points 
to the geofeed [RFC8805] file provides some assurance. Unfortunately, the RPSL in many 
repositories is weakly authenticated at best. An approach where RPSL was signed per [RFC7909] 
would be good, except it would have to be deployed by all RPSL registries, and there is a fair 
number of them. 


A single optional authenticator MAY be appended to a geofeed [RFC8805] file. It is a digest of the 
main body of the file signed by the private key of the relevant RPKI certificate for a covering 
address range. One needs a format that bundles the relevant RPKI certificate with the signature 
of the geofeed text. 


The canonicalization procedure converts the data from their internal character representation to 
the UTF-8 [RFC3629] character encoding, and the <CRLF> sequence MUST be used to denote the 
end of a line of text. A blank line is represented solely by the <CRLF> sequence. For robustness, 
any non-printable characters MUST NOT be changed by canonicalization. Trailing blank lines 
MUST NOT appear at the end of the file. That is, the file must not end with multiple consecutive 
<CRLF> sequences. Any end-of-file marker used by an operating system is not considered to be 
part of the file content. When present, such end-of-file markers MUST NOT be processed by the 
digital signature algorithm. 


Should the authenticator be syntactically incorrect per the above, the authenticator is invalid. 


Borrowing detached signatures from [RFC5485], after file canonicalization, the Cryptographic 
Message Syntax (CMS) [RFC5652] would be used to create a detached DER-encoded signature that 
is then padded BASE64 encoded (as per Section 4 of [RFC4648]) and line wrapped to 72 or fewer 
characters. The same digest algorithm MUST be used for calculating the message digest on 
content being signed, which is the geofeed file, and for calculating the message digest on the 
SignerInfo SignedAttributes [RFC8933]. The message digest algorithm identifier MUST appear in 
both the SignedData DigestAlgorithmIdentifiers and the SignerInfo DigestAlgorithmIdentifier 
[RFC5652]. 


The address range of the signing certificate MUST cover all prefixes in the geofeed file it signs. 


An address range A "covers" address range B if the range of B is identical to or a subset of A. 
"Address range" is used here because inetnum: objects and RPKI certificates need not align on 
Classless Inter-Domain Routing (CIDR) [RFC4632] prefix boundaries, while those of the CSV lines 
in a geofeed file do. 


Bush, et al. Standards Track Page 5 


RFC 9092 Finding Geofeeds July 2021 


As the signer specifies the covered RPKI resources relevant to the signature, the RPKI certificate 
covering the inetnum: object's address range is included in the [RFC5652] CMS SignedData 
certificates field. 


Identifying the private key associated with the certificate and getting the department that 
controls the private key (which might be trapped in a Hardware Security Module (HSM)) to sign 
the CMS blob is left as an exercise for the implementor. On the other hand, verifying the 
signature requires no complexity; the certificate, which can be validated in the public RPKI, has 
the needed public key. The trust anchors for the RIRs are expected to already be available to the 
party performing signature validation. Validation of the CMS signature on the geofeed file 
involves: 


1. Obtaining the signer's certificate from the CMS SignedData CertificateSet [RFC5652]. The 
certificate SubjectKeyIdentifier extension [RFC5280] MUST match the SubjectKeyldentifier in 
the CMS SignerInfo Signerldentifier [RFC5652]. If the key identifiers do not match, then 
validation MUST fail. 


Validation of the signer's certificate MUST ensure that it is part of the current [RFC6486] 
manifest and that the resources are covered by the RPKI certificate. 


2. Constructing the certification path for the signer's certificate. All of the needed certificates 
are expected to be readily available in the RPKI repository. The certification path MUST be 
valid according to the validation algorithm in [RFC5280] and the additional checks specified 
in [RFC3779] associated with the IP Address Delegation certificate extension and the 
Autonomous System Identifier Delegation certificate extension. If certification path 
validation is unsuccessful, then validation MUST fail. 

3. Validating the CMS SignedData as specified in [RFC5652] using the public key from the 
validated signer's certificate. If the signature validation is unsuccessful, then validation MUST 
fail. 

4. Verifying that the IP Address Delegation certificate extension [RFC3779] covers all of the 
address ranges of the geofeed file. If all of the address ranges are not covered, then 
validation MUST fail. 


All of these steps MUST be successful to consider the geofeed file signature as valid. 


As the signer specifies the covered RPKI resources relevant to the signature, the RPKI certificate 
covering the inetnum: object's address range is included in the CMS SignedData certificates field 
[RFC5652]. 


Identifying the private key associated with the certificate and getting the department with the 
Hardware Security Module (HSM) to sign the CMS blob is left as an exercise for the implementor. 
On the other hand, verifying the signature requires no complexity; the certificate, which can be 
validated in the public RPKI, has the needed public key. 
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The appendix MUST be hidden as a series of "#" comments at the end of the geofeed file. The 
following is a cryptographically incorrect, albeit simple, example. A correct and full example is in 
Appendix A. 


RPKI Signature: 192.0.2.0 - 192.0.2.255 
MIIGlwYJKoZIhvcNAQcCoIIGiDCCBoQCAQMxDTALBglghkgBZQMEAgEwDQYLKoZ 
IhvcNAQkQAS-*gggSxMIIErTCCA5WgAwIBAgIUJ605QIPX8rW5m4Zwx3WyuW7hZu 


imwYkXpiMxwA4EZqD j 136MiWsRDLdgoijBBcGbibwyAfGeR46k5raZCGvxG+4xa 
O8PDTXxTfIYwAnBjRBKAqAZ7yX5xHfm58jUXsZJ711eq1S7G6Kk- 
End Signature: 192.0.2.0 - 192.0.2.255 


HHH: HHH 


The signature does not cover the signature lines. 


The bracketing "# RPKI Signature:" and "# End Signature:" MUST be present following the model 
as shown. Their IP address range MUST match that of the inetnum: URL followed to the file. 


[RPKI-RSC] describes and provides code for a CMS profile for a general purpose listing of 
checksums (a "checklist") for use with the Resource Public Key Infrastructure (RPKT). It provides 
usable, albeit complex, code to sign geofeed files. 


[RPKI-RTA] describes a CMS profile for a general purpose Resource Tagged Attestation (RTA) 
based on the RPKI. While this is expected to become applicable in the long run, for the purposes 
of this document, a self-signed root trust anchor is used. 


5. Operational Considerations 


To create the needed inetnum: objects, an operator wishing to register the location of their 
geofeed file needs to coordinate with their Regional Internet Registry (RIR) or National Internet 
Registry (NIR) and/or any provider Local Internet Registry (LIR) that has assigned address ranges 
to them. RIRs/NIRs provide means for assignees to create and maintain inetnum: objects. They 
also provide means of assigning or sub-assigning IP address resources and allowing the assignee 
to create WHOIS data, including inetnum: objects, thereby referring to geofeed files. 


The geofeed files MUST be published via and fetched using HTTPS [RFC2818]. 


When using data from a geofeed file, one MUST ignore data outside the referring inetnum: 
object's inetnum: attribute address range. 


If and only if the geofeed file is not signed per Section 4, then multiple inetnum: objects MAY 
refer to the same geofeed file, and the consumer MUST use only lines in the geofeed file where 
the prefix is covered by the address range of the inetnum: object's URL it has followed. 


If the geofeed file is signed, and the signer's certificate changes, the signature in the geofeed file 
MUST be updated. 
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It is good key hygiene to use a given key for only one purpose. To dedicate a signing private key 
for signing a geofeed file, an RPKI Certification Authority (CA) may issue a subordinate certificate 
exclusively for the purpose shown in Appendix A. 


To minimize the load on RIR WHOIS [RFC3912] services, use of the RIR's FTP [RFC0959] services 
SHOULD be used for large-scale access to gather geofeed URLs. This also provides bulk access 
instead of fetching by brute-force search through the IP space. 


Currently, geolocation providers have bulk WHOIS data access at all the RIRs. An anonymized 
version of such data is openly available for all RIRs except ARIN, which requires an 
authorization. However, for users without such authorization, the same result can be achieved 
with extra RDAP effort. There is open-source code to pass over such data across all RIRs, collect 
all geofeed references, and process them [GEOFEED-FINDER]. 


To prevent undue load on RPSL and geofeed servers, entity-fetching geofeed data using these 
mechanisms MUST NOT do frequent real-time lookups. Section 3.4 of [RFC8805] suggests use of 
the HTTP Expires header [RFC7234] to signal when geofeed data should be refetched. As the data 
change very infrequently, in the absence of such an HTTP Header signal, collectors SHOULD NOT 
fetch more frequently than weekly. It would be polite not to fetch at magic times such as 
midnight UTC, the first of the month, etc., because too many others are likely to do the same. 


6. Privacy Considerations 


[RFC8805] geofeed data may reveal the approximate location of an IP address, which might in 
turn reveal the approximate location of an individual user. Unfortunately, [RFC8805] provides no 
privacy guidance on avoiding or ameliorating possible damage due to this exposure of the user. 
In publishing pointers to geofeed files as described in this document, the operator should be 
aware of this exposure in geofeed data and be cautious. All the privacy considerations of Section 
4 of [RFC8805] apply to this document. 


Where [RFC8805] provided the ability to publish location data, this document makes bulk access 
to those data readily available. This is a goal, not an accident. 


7. Security Considerations 


It is generally prudent for a consumer of geofeed data to also use other sources to cross validate 
the data. All the security considerations of [RFC8805] apply here as well. 


As mentioned in Section 4, many RPSL repositories have weak, if any, authentication. This allows 
spoofing of inetnum: objects pointing to malicious geofeed files. Section 4 suggests an 
unfortunately complex method for stronger authentication based on the RPKI. 


For example, if an inetnum: for a wide address range (e.g., a /16) points to an RPKI-signed 
geofeed file, a customer or attacker could publish an unsigned equal or narrower (e.g., a /24) 
inetnum: in a WHOIS registry that has weak authorization, abusing the rule that the most- 
specific inetnum: object with a geofeed reference MUST be used. 
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If signatures were mandatory, the above attack would be stymied, but of course that is not 
happening anytime soon. 


The RPSL providers have had to throttle fetching from their servers due to too-frequent queries. 
Usually, they throttle by the querying IP address or block. Similar defenses will likely need to be 
deployed by geofeed file servers. 


8. IANA Considerations 


IANA has registered object identifiers for one content type in the "SMI Security for S/MIME CMS 
Content Type (1.2.840.113549.1.9.16.1)" registry as follows: 


Decimal Description References 
47 id-ct-geofeedCSVwithCRLF RFC 9092 
Table 1 
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datatracker.ietf.org/doc/html/draft-ietf-sidrops-rpki-rta-00>. 
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This appendix provides an example that includes a trust anchor, a CA certificate subordinate to 
the trust anchor, an end-entity certificate subordinate to the CA for signing the geofeed, and a 
detached signature. 


The trust anchor is represented by a self-signed certificate. As usual in the RPKI, the trust anchor 
has authority over all IPv4 address blocks, all IPv6 address blocks, and all Autonomous System 
(AS) numbers. 


Sa BEGIN CERTIFICATE----- 

MIIEPjCCAyagAWIBAgIUPSUF J4e/7pKZ6E14aBdkbYzms1 gwDQY JKoZIhvcNAQEL 
BQAwF TETMBEGA1UEAXMKZXhhbXBsZS10Y TAeFw@yMDA5MDMxODU@NTRaFw@zMDA5 
MDE xODU@NTRaMBUXEZARBgNVBAMTCmV4YW1wbGUtdGEwggEiMA@GCSqGSIb3DQEB 
AQUAA4TBDwAwggEKAoIBAQCe1MmMDCGBhqn/a3VrNAoKMr1HVLKxGoG7VF/13HZJ 
@twObUZ1h3Jz+XeD+kNAURhHELWT rsgdTkQQfqinqOuRemxT155+x7nLpe5SnmwaBH 
XqqDOHubmkbAGanGem6T / rD9KNk1Z46Uc2p7UYu@fwNO@mo@aqFL2FSyvzZwziNe 
g7ELYZAa3LvGn81 JfP/JvM6pgtoMNuee5RV6TWaz7LV304ICj 8Bhphy /HFpOA1rb 
09gs8CUMgqz-*RroAIa8cV8gbF/fPCz90f17Gdmib679JxxF rWAwRJOnMJgJmsZXq 
jaVc0g70Rc*elIAcHw7Uroc6h7Y71GjOkDZF75j0mLQa3AgMBAAG j ggGEMIIBgDAd 
BgNVHQAEFgQU3hNEuwvUGNCHY 1 TBatcURO3pNdYwHwYDVRO j BBgwFoAUS3hNEuwvU 
GNCHY 1 TBatcUR03pNdYwDwYDVROTAOH / BAUWAWEB / ZAOBgNVHQ8BAf 8EBAMCAQYw 
GAYDVRO0gAQH/BAA4wDDAKBgg rBgEFBQcOA j CBuQYIKwYBBQUHAQsEgawwgakwPgYI 
KwYBBQUHMAqGMnJzeW5jOi8vcnBraS5leGFtcGxlLm51dC9yZXBvc210b3J5L2V4 
YW1wbGUtdGEubWZ0MDUGCCsGAQUFBzANhilodHRwczovL3JyZHAuZXhhbXBsZS5u 
ZXQvbm90aWZpY2F0aW9uLnhtbDAwBgg rBgEFBQcwBYYkcnN5bmM6Ly9ycGtpLmVA 
YW1wbGUubmV8L3J1cG9zaXRvcnkvMCcGCCsGAQUFBwEHAQH / BBgwF j AJBAIAATAD 
AwEAMAKEAgACMAMDAQAwHgY IKwY BBQUHAQgEE j AQoA4WDDAKAgEAAgUA / / / / / ZAN 
BgkqhkiG9wOBAQsFAAOCAQEAgZFQOSf3CI5Hwev61AUWHYOFniy69PuDTq-*WnhDe 
xX5rpjSDRrs5L756KSKJca0J361z0451fOPSYOfH6x30pnipaqRA7t5rApky24jH 
cSUA9iRednzxhVyGjWKnf AKyNo2MY fa0AT@db1Gj yLKbOADI9FowtHBUu-60ykcM 
Quz66XrzxtmxlrRcAnbv /HtV17g0d4my6q5y j TPR1dmYN90R/2Ch1XtGE6uQVguA 
rvNZ5CwiJ1TgGGTB7T80RHwWU6dGTc@jk2rESAaikmLil roZSNC21fckhapEit1a 
x8CyiVxjcVc5e0@AmS1rJfL6LIfwmtive/N/eBtIM92HkBA== 

PIE, END CERTIFICATE----- 
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The CA certificate is issued by the trust anchor. This certificate grants authority over one IPv4 
address block (192.0.2.0/24) and two AS numbers (64496 and 64497). 


SSS BEGIN CERTIFICATE----- 
MIIFBzCCA++gAwIBAgIUcyCzS10hdfG65kbRq7toQAvRDKowDQY JKoZIhvcNAQEL 
BQAwFTETMBEGATUEAxMKZXhhbXBsZS10YTAeFwOyMDASMDMXxOTAyMTlaFwOyMTA5S 
MDMxOTAyMTlaMDMxMTAvBgNVBAMTKDNBQOUyQOVGNEZCM j FCNOQXMUUzRTEANEVG 
QzFFMjk3QjM3Nzg2NDIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAOIBAQDc 
zziqwTxC20cw5rqp8ktm2XyYk18riBVuqlXwfefTxsR2YFpgz9vkYUd5Az9EVEG7 
6wGIyZbtmhK63eEeaqbKz2GHub467498BXeVrYysO-*YuIGgCEYKznNDZ4 j5aaDbo 
j5*4/z0Qvv6HEsxQd8f8br61KJwgeRM6--fm7796HNPB0aqD7Z j 9NRCLX jbBeDCgJ 
liH6rXMKR860fg119V2mRjesvhdKYgkGbOif9rvxVpLJ/6zdru5CE9yeuJZ591-4n 
YH/r6PzdJ4Q7yKr JX8qD6A60 j 4*biaUAMQ72Kps jhQNTTqF /HRwi@N54GDaknEwE 
TnJQHgL JDYqww9yKWt j j AgMBAAG j gg I VMIICKZAdBgNVHQ4EF gQU0s4s70+yG30R 
4*GE78Hi17N3hkIwHwYDVRO jBBgwFoAU3hNEuwvUGNCHY 1TBatcURO3pNdYwDwYD 
VROTAQH/BAUWAWEB / ZAOBgNVHQ8BAf 8EBAMCAQYwGAYDVR@gAQH/BA4wDDAKBggr 
BgEFBQcOAjBhBgNVHR8EWjBYMFagVKBSh1Byc3luYzovL3Jwa2kuZXhhbXBsZSb5u 
ZXQvcmVwb3NpdG9yeS8zQUNFMkNFRjRGQj IxQjdEMTFFMOUxODRFRKkMxRTISNOIz 
Nzc4NjQyLmNybDBOBgg r BgEFBQcBAQRCMEAwPgY IKwYBBQUHMAKGMnJz eW5 jOi8v 
cnBraS5leGFtcGx1Lm51dC9yZXBvc210b3J5L2V4YW1wbGUtdGEuY2VyMIG5Bggr 
BgEFBQcBCwSBrDCBqTA+BggrBgEFBQcwCoYycnN5SbmM6L y9ycGtpLmV4YW1wbGUu 
bmVOL3JlcG9zaXRvcnkvZXhhbXBsZS1 j YS5tZnQwNQYIKwYBBQUHMA2GKWhOdHBz 
Oi8vcnJkcC5leGFtcGxlLm51dC9ub3RpZzml;jYXRpb24ueG1sMDAGCCsGAQUFBZzAF 
hiRyc3luYzovL3Jwa2kuZXhhbXBsZS5uZXQvcmVwb3NpdG9yeS8wHwY IKwYBBQUH 
AQcBAf 8EEDAOMAWEAgABMAYDBADAAAIwHgY IKwY BBQUHAQGEE j AQOA4wDDAKAgMA 
+/ACAwD78TANBgkqhkiG9w@BAQsF AAOCAQEAnLu+d1ZsUTiX3YWGueTHIalW4ad@ 
Kupi7pYMV2nXbxNGmdJMol9BkzVz9tj 55ReMghUU4YLm/ICYe4fz5e@T809s/vim 
cGS29+WoGuiznMitpvbS/379gaMezk6KpqjH6Brw6meMqy89phmcmvm3 x3WTmx09 
mL1QneMptwk8qSYcnMUmGL Js-*cVqmk0a3 sWNRdw8WrGu6QqYtQz3HFZQo j F06YzEq 
V/dBdCFdEOwTfV12n2XqhoJ1/oEBdC4uu2GO0qRk3-WV s-uwVHPOTtsbt7TzFgZfY 
yxqv0g6QoldxZVzmHHncKmETu /BqCDGJot9may31ukrx34Bu-*XFMVihm0w-- 
SSS END CERTIFICATE----- 
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The end-entity certificate is issued by the CA. This certificate grants signature authority for one 
IPv4 address block (192.0.2.0/24). Signature authority for AS numbers is not needed for geofeed 
data signatures, so no AS numbers are included in the certificate. 


SSS BEGIN CERTIFICATE----- 
MITEpTCCA42gAwIBAgIUJ605QIPX8rW5m4Zwx3WyuW7hZuQwDQY JKoZIhvcNAQEL 
BQAwMzExMC8GA1UEAXxMoMOFDRTJDRUYORKIyMUISRDEXRTNFMTgORUZDMUUyOTdC 
Mzc30DY0M jAeFwOyMTA1MjAxNjA1NDVaFw8OyMjAzMTYxN jA1NDVaMDMxMTAvBgNV 
BAMTKDkxNDY 1MkEZQkQ1MUMxNDQyN j AXOTg40D1GNUM@NUFCR j A 1M8ExODcwggE i 
MA0GCSqGSIb3DQEBAQUAAAIBDwAWggEKAOIBAQCycTQrOb/qB2W3i3Ki8PhA/DEW 
yii2TgGo9pgCwO91sIRI6Zb/k-*aSiWWP9kSczlcQgtPCVwr62hTQZCIowBNOBLOC 
K0/5k1imJdi5qdM3nvKswM8CnoR11vB8pQFwruzmr5xphXRvE-*mzuJVLgu2V1upm 
BXuWloeymudh6WWJ+GD jwPXO3RiXBe;jBrOFNXhaFLe08y4DPf r/S/tXJOBm7QzQp 
tmbPLYtGfprYu451iFFqqP94UeLpISfXd36AKGzqTFCcc3EW915UFE1MFLInoEog 
qtoLoKABt@IkOFGKeC/EgeaBdWLe469ddC9rQft 5w6g6cmxG+aYDdIEB34zrAgMB 
AAGjggGvMIIBqzAdBgNVHQAEF gQUKkUZSo71RwUQmAZiInixFq/BToYcwHwYDVRO j 
BBgwFoAUOs4s70*yG30R4-*GE78Hil7N3hkIwDAYDVROTAQH /BAIWADAOBgNVHQ8B 
Af8EBAMCBAAwGAYDVROgAQH / BAAWDDAKBgg r BgEFBQcOA j BhBgNVHR8EWjBYMFag 
VKBSh1Byc3luYzovL3Jwa2kuZXhhbXBsZS5uZXQvcmVwb3NpdG9yeS8zQUNFMKkNF 
RjRGQjIxQjdEMTFFMOUxODRFRKMxRTISNOIzNzc4NjQyLmNybDBsBggrBgEFBQcB 
AQRgMFAwXAY IKwYBBQUHMAKGUHJZeW5 j O18vcnBraS5leGFtcGxlLm51dC9yZXBv 
c210b3J5LzNBQOUyQOVGNEZCM j FCNOQXMUUZRTEANEVGQzFFMjk3QjM3Nzg2NDIu 
Y2VyMBkGCCsGAQUFBwEHAQH / BAowCDAGBAIAAQUAMEUGCCSGAQUF BWwELBDkWwNZzA 1 
BggrBgEFBQcwDYYpaHR@cHM6L y9ycmRwLmV4YW1wbGUubmV@L25vdGlmaWNhdGlv 
bi54bWwwDQY JKoZIhvcNAQELBQADggEBAE j C98gVp0Mb7uiKaHylP0453mtJ-AkN 
07fsK/qGw/e90DJv7cpi1hvj j4uy3sgf7PJQ7cKNGrgybq/1E@jcet+tARgVjbi2Brz 
ZsWAnB846Snwsktw6cenaif6Aww6q00NspAepMBd2Vg/9sKFvOwJFVOgNcqiQiXP 
5rGJPWBcOMv52a/7adjfXwpnOijiTOgMloQGmC2TPZpydZKjlxEATdFEQssa33xD 
nlpp*/r9xuNVYRtRcC360WraVA3jzN6F6rDE8r8xs3ylISVz6JeCQAYRYwbMs j jc 
/t*iJLM7ZYxIe5IrYz1ZtN6n/SEssJAswRIgps2bEhCt/HS2xAmGCOhgU- 

SSeS END CERTIFICATE----- 
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The end-entity certificate is displayed below in detail. For brevity, the other two certificates are 
not. 
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REC 9092 
0 1189 
4 909 
8 
10 
13 20: 
35 13: 
37 
48 
58 51 
52 49 
54 47 
56 
61 40: 
103 30: 
105 13: 
120 13: 
135 51 
137 49 
139 47 
141 
146 40: 
188 290: 
192 13: 
194 
205 
207 271: 
212 266: 
216 257: 
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: SEQUENCE { 


SEQUENCE { 
[a] 
INTEGER 2 


} 
INTEGER 27AD394083D7F2B5B99B8670C775B2B96EE166E4 
SEQUENCE { 
OBJECT IDENTIFIER 
sha256WithRSAEncryption (1 2 840 113549 1 1 11) 
NULL 


} 
SEQUENCE { 
SET { 
SEQUENCE { 
OBJECT IDENTIFIER commonName (2 5 4 3) 
PrintableString 
' SACE2CEF4FB21B7D11E3E184EFC1E297B3778642' 
} 
} 


} 
SEQUENCE { 
UTCTime 20/05/2021 16:05:45 GMT 
UTCTime 16/03/2022 16:05:45 GMT 


} 
SEQUENCE { 
SET { 
SEQUENCE { 
OBJECT IDENTIFIER commonName (2 5 4 3) 
PrintableString 
'914652A3BD51C144260198889F5C45ABF053A187' 
} 
} 


} 
SEQUENCE { 
SEQUENCE { 
OBJECT IDENTIFIER rsaEncryption 
(1 2 840 113549 1 1 1) 
NULL 


} 

BIT STRING, encapsulates { 

SEQUENCE { 
INTEGER 
00 B2 71 34 2B 39 BF EA 97 65 B7 8B 72 A2 F0 
40 FC 31 16 CA 28 B6 4E 01 A8 F6 98 02 CO EF 
BO 84 48 E9 96 FF 93 E6 92 89 65 8F F6 44 9C 
57 10 82 D3 C2 57 OA FA DA 14 DO 64 22 28 CO 
74 04 BD 1C 2B 4F F9 93 58 A6 25 D8 B9 A9 D3 
9E F2 AC CO CF 02 9E 84 75 D6 F0 7C A5 01 70 
E6 66 AF 9C 69 85 74 6F 13 E9 B3 B8 95 4B 82 
95 Dé EA 66 05 7B 96 96 87 B2 9A E7 61 E9 65 
F8 60 E3 CO F5 CE DD 18 97 805 E8 C1 AC E1 4D 
16 85 2D ED 3C CB 80 CF 7E BF D2 FE D5 C9 38 
BB 43 34 29 B6 66 CF 2D 8B 46 7E 9A D8 BB 8E 
88 51 6A A8 FF 78 51 E2 E9 21 27 D7 77 7E 80 
6C EA 4C 50 9C 73 71 16 F6 5E 54 14 4D 4C 14 
67 A0 4A 20 AA DA 0B AO AO 01 B7 42 24 38 51 
78 2F C4 81 E6 81 75 62 DE E3 AF 5D 74 2F 6B 
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477 


482 
486 
490 
492 
497 
499 


521 
523 
528 
530 
532 


554 
556 
561 
564 
566 


568 
570 
575 
578 
580 


584 
586 
591 
594 
596 
598 
600 


610 
612 
617 
619 
621 
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FB 79 C3 A8 3A 72 6C 46 F9 A6 03 74 81 01 DF 8C 
EB 
INTEGER 65537 

} 

} 


} 
[3] { 


SEQUENCE { 
SEQUENCE { 
OBJECT IDENTIFIER subjectKeyIdentifier (2 5 29 14) 
OCTET STRING, encapsulates { 
OCTET STRING 
91 46 52 A3 BD 51 C1 44 26 01 98 88 9F 5C 45 AB 
E0553 ^11787 


} 


} 
SEQUENCE { 
OBJECT IDENTIFIER authorityKeyIdentifier (2 5 29 35) 
OCTET STRING, encapsulates { 
SEQUENCE { 
[0] 
SASGES2USERTAESB2OHUBOZDS TISESXET?SA2EESCTRE2307 
B3 77 86 42 
} 
} 


} 
SEQUENCE { 
OBJECT IDENTIFIER basicConstraints (2 5 29 19) 
BOOLEAN TRUE 
OCTET STRING, encapsulates { 
SEQUENCE {} 
} 


} 
SEQUENCE { 
OBJECT IDENTIFIER keyUsage (2 5 29 15) 
BOOLEAN TRUE 
OCTET STRING, encapsulates { 
BIT STRING 7 unused bits 
'1'B (bit 60) 
} 


} 
SEQUENCE { 
OBJECT IDENTIFIER certificatePolicies (2 5 29 32) 
BOOLEAN TRUE 
OCTET STRING, encapsulates { 
SEQUENCE { 
SEQUENCE { 
OBJECT IDENTIFIER 
resourceCertificatePolicy (1 3 6 1 5 5 7 14 2) 
} 
} 
: 


} 
SEQUENCE { 
OBJECT IDENTIFIER cRLDistributionPoints (2 5 29 31) 
OCTET STRING, encapsulates { 

SEQUENCE { 

SEQUENCE { 
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623 
625 
627 


709 
711 


721 
723 
725 
2 
737 


819 
821 
831 
834 
836 
838 
840 
844 


846 
848 


858 
860 
862 
864 
874 


917 
919 


930 


Bush, et al. 


84: 
82: 
80: 
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'rsync://rpki.example.net/repository/3ACE2CEFAF ' 
'B21B7D11E3E184EFC1E297B3778642 .cr1' 
} 
} 
y 
} 
} 


} 
SEQUENCE { 
OBJECT IDENTIFIER authorityInfoAccess 
(GUESS Ge e595: 975 19) 
OCTET STRING, encapsulates { 
SEQUENCE { 
SEQUENCE { 
OBJECT IDENTIFIER caIssuers (1 3 6 1 5 5 7 48 2) 
[6] 
'rsync://rpki.example.net/repository/3ACE2CEFAF ' 
'B21B7D11E3E184EFC1E297B3778642 .cer' 
} 
} 
} 


} 
SEQUENCE { 
OBJECT IDENTIFIER ipAddrBlocks (1 3 6 1 5 5 7 1 7) 
BOOLEAN TRUE 
OCTET STRING, encapsulates { 
SEQUENCE { 
SEQUENCE { 
OCTET STRING 00 01 
NULL 
} 
} 
} 


} 
SEQUENCE { 
OBJECT IDENTIFIER subjectInfoAccess 
CAE Ton ES S EANES 
OCTET STRING, encapsulates { 
SEQUENCE { 
SEQUENCE { 
OBJECT IDENTIFIER ‘1 3 6 1 5 5 7 48 13° 
[6] 


'https://rrdp.example.net/notification.xml' 


} 

SEQUENCE { 

OBJECT IDENTIFIER sha256WithRSAEncryption 
(1 2 848 113549 1 1 11) 

NULL 


} 
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932 257: BIT STRING 
: 48 C2 F7 C8 15 A7 43 1B EE E8 8A 68 7C A5 3F 4E 
39 DE 6B 49 F8 09 0D D3 B7 EC 2B FA 86 C3 F7 BD 
DO 32 6F ED CA 75 86 F8 E3 E2 EC B7 B2 07 FB 3C 
94 3B 70 A3 46 AE 0C 9B AB F9 44 D2 37 1E F8 04 
60 56 36 E2 D8 1A F3 66 C5 80 9C 1F 38 E9 29 FO 
B2 4B 70 E9 C7 A7 6A 27 FA 03 0C 3A AB 4D 0D B2 
90 1E A4 CO 5D DO 58 3F F6 C2 85 BC EC 09 15 53 
AO 35 CA A2 42 25 CF E6 B1 89 3D 60 5C 38 CB F9 
D9 AF FB 69 D8 DF 5F 0A 67 3A 28 E2 4C E8 0C 96 
84 06 98 2D 93 3D 9A 72 75 92 A3 97 11 00 4D D1 
44 42 CB 1A DF 7C 43 9E 5A 69 FB FA FD C6 E3 55 
61 1B 51 70 2D FA A1 6A DA 54 0D ES3 CC DE 85 EA 
BO C4 F2 BF 31 B3 7C A5 21 25 73 E8 97 82 43 86 
11 63 06 CC B2 38 DC FE D8 89 2C CE D9 63 12 1E 
E4 8A D8 CF 56 6D 37 A9 FF 48 4B 2C 24 0B 30 44 
88 29 B3 61 21 0A DF C7 4B 6C 40 98 60 8E 86 05 


} 


To allow reproduction of the signature results, the end-entity private key is provided. For brevity, 
the other two private keys are not. 


MIIEpQIBAAKCAQEAsnEOKzm/6gdlt4tyovDAQPwxFsootk4BqPaYAsDvZbCESOmW 
/5Pmko11j/ZEnM5XEILTwlcK4*toUOGQiKMATdAS9HCtP-*ZNYpiXYuanTN57yrMDP 
Ap6EddbwfKUBcK7mZq-*caYVObxPps7iVS4LtldbqZgV71lpaHsprnYellifhg48D1 
ZtOY lwXowazhTV4WhS3 t PMuAz36 /0v7VyTgZu0MOKbZmzy2L Rn6a2LuOZYhRaqj / 
eFHi6SEn13d+gChs6kxQnHNxFvZeVBRNTBS5Z6BKIKraC6CgAbdCJDhRingvxIHm 
gXVi3uOvXXQva0H7ecOo0nJsRvmmA3SBAd-*M6wIDAQABAOIBAQCyBOFeMuKm8bRo 
18aKjFGSPEoZi53srIz5bvUgli92TBLez7ZnzL6Iym260J-*5th-*1CHGO/dqlhXio 
pI50C5Yc9TFbblb/ECOsuCuuqKF jZ8CD3GVsHozXKJeMM- / o5YZXQrORj6UnwTOz 
01/JE5pIGUCIgsXX6tz9s5BP31UAvVQHsv6-*vEVKLxQ3wj /1vIL80/CN036EV0GJ 
mpkwmygP j fECT9wbWo@yn3 j xJb36+M/Qj jUP28o0NIVn/IKoPZRXnqchEbuuCJ651 
IsaFSqtiThm4WZtvCH/IDq-*6/dcMucmTjIRcYwW7fdHf jplllVPve9c/OmpWEQvF 
t3ArWUt 5A0GBANS4764yHxo4mctLIE7G71/tf9bP4KKUiYw4R4ByEocuqMC4yhmt 
MPCFOFLOQet710WCkjP2L/7EKUe9yx7G5KmxAHY6 j0j vcRkvGs161WFOsSQ8p126M 
Y9hmGZMOj tsdhAiMmOWKzj vm4Wq fMgghQe+Pnj jSVkgTt+7BxpIuGBAVAoGBANBg 
26FF5cDLpixOd3Za1YXsOgguwCaw3Plvi7vUZRpa/zBMELEtyOebfakkIRWNm071 
nE-lAZwxm-29PTDOnqCFE91teyzjnQaLOS5kkAdJiFuVV3icLOGo399FrnJbKensm 
FGSli-3KxQhCNIJJfgWzq4bEO0ioAMjdGbYXzIYQFAoGBAM6tuDJ36KDU-*hIS6wu6 
O2TPSfZhF /zPo3pCWQ78 /QDb*ZdwAIEiqoBA7FANPVLg9Y /H8UTx9r / veqe7hPOo 
Ok7NpIzSmKTHkc5XfZ60Zn90LFoKbaQ40a1kXoJdWEu2YROaUl1Ae9F6 /Rog6PHYz 
vLE5qscRbuOXQhLkN*z7bg5bAoGBAKDsbDEb /dbqbyaAYpmwhH2 sdRSkphg7Niwc 
DNm9qWa1J6Zw1-M8716Q8naRREuU1IAVqqWHVLr /ROBQ6NTJ1Uc5/qFeT2XXUgkf 
taMKv61tuyjZK3sTmznMh0Hf ZUpWj EhWnCEuB+ZYVdm052ZGw2A75RdrILL2+9Dc 
PvDXVubRAoGAdqXeSWoLxuzZXz18rsaKrQsTYaXnOWaZieU1SL5vVe8nK257UDqZ 
E3ng2 j 5XPTUW1i+taNGFEJGRoNtcQv0600/sFZUhu52sqq9mWVYZNh1 TB5aP8X+pV 
iFcZOLUVQECN6PA+YQK5FU11 rAI1M@Gm5RDnVnNULOL2xfCYxb7FzV6Y= 

pagaz END RSA PRIVATE KEY----- 
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Signing of "192.0.2.0/24,US,WA, Seattle," (terminated by CR and LF) yields the following detached 
CMS signature. 


HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH HHH HH SE 


RPKI Signature: 192.0.2.0 - 192.0.2.255 

MIIGjwYJKoZIhvcNAQcCoIIGgDCCBnwCAQMxDTALBglghkgBZQMEAgEwDQYLKoZ 
IhvcNAQkQAS-*gggSpMIIEpTCCA42gAwIBAgIUJ605QIPX8rW5m4Zwx3WyuW7hZu 
QwDQY JKoZIhvcNAQELBQAWMzE xMC8GA1UEAXMoMOFDRT JDRUYORKIyMUISRDEXxR 
TNFMTgORUZDMUUyOTdCMz c30DY0M j AeFwOyMTA1Mj AxN j ATNDVaFwOyM j AZMTYx 
NjA1NDVaMDMXxMTAvBgNVBAMTKDKkXxNDY 1MkEzQkQ1MUMXNDQyN j AxOTg40D1GNUM 
QNUFCRjA1MOExODcwggEiMA0GCSqGSIb3DQEBAQUAAA4IBDwAwggEKAOIBAQCycT 
QrOb/qB2W3i3Ki8PhA/DEWyii2TgGo9pgCwO9lsIRI6Zb/k*aSiWWPO9kSczlcQg 
tPCVwr62hTQZCIowBNOBLOCKO /5k1imJdi5qdM3nvKswM8CnoR11vB8pQFwruzm 
r5xphXRvE+mzuJVLgu2V1upmBXuWloeymudh6WWJ+GDjwPX03RixXBejBrOFNXha 
FLe08yA4DPfr/S/tXJOBm7QzQptmbPLYtGfprYu4A5liFFqqP94UeLpISfXd36AKG 
zqIFCcc3bEW915UFE1MFLlInoEogqtoLoKABtOIKOFGKeC/EgeaBdWLe469ddC9rQ 
ft5w6g6cmxG*aYDdIEB34zrAgMBAAG j ggGvMIIBqzAdBgNVHQ4EF gQUKUZSo71R 
wUQmAZ iln1xFq/BToYcwHwYDVRO j BBgwFoAU0s4s 70+yG30R4+GE78Hil7N3hkI 
wDAYDVROTAOH/BAIWADAOBGNVHQ8BAf 8EBAMCBA4AwGAY DVROgAQH / BAAWDDAKBg 
grBgEFBQcOAjBhBgNVHR8EWj BYMFagVKBSh1Byc3luYzovL3Jwa2kuZXhhbXBsZ 
S5uZXQvcmVwb3NpdG9yeS8zQUNFMKNFR j RGQj IxQ j dEMTFFMOUxODRFRKMXxRTI5 
NOIzNzcANjQyLmNybDBsBggrBgEFBQcBAQRgMF AwXAYIKwYBBQUHMAKGUHJZz eW5 
jOi8vcnBraS5leGFtcGxlLm51dC9yZXBvc210b3J5LzNBQOUyQOVGNEZCM j FCNO 
QxMUUZRTEANEVGQzFFMj k3QjM3Nzg2NDIuY2VyMBkGCCsGAQUFBwEHAQH / BAowC 
DAGBAIAAQUAMEUGCCSGAQUFBWELBDKkwNzA1Bgg rBgEFBQcwDY YpaHROcHM6Ly9y 
cmRwLmV4YW1wbGUubmV@L2 5vdG1lmaWNhdGlvbi54bWwwDQYJKoZThvcNAQELBQA 
DggEBAE j C98gVp0Mb7uiKaHylP0453mtJ-*AkN07f sK/qGw/e90DJv7cp1hvj j4u 
y3sgf7PJQ7cKNGrgybq/1E0jce*ARgVjbi2BrzZsWAnB846Snwsktw6cenaif6A 
ww6q800NspAepMBd2Vg/9sKFvOwJFVOgNcqiQiXP5rGJPWBcOMv52a/7adjfXwpn 
OijiTOgMloQGmC2TPZpydZKjlxEATdFEQssa33xDnlpp-*/r9xuNVYRtRcC360Wr 
aVA3jzN6F6rDE8r8xs3ylISVz6JeCQAYRYwbMsj jc/tiJLM7ZYxIe5IrYz1ZtN6 
n/SEssJAswRIgps2EhCt/HS2xAmGCOhgUxggGqMIIBpglIBAA4AUKUZSO7 1RwUQmA 
ZilnixFq/BToYcwCwYJYIZIAWUDBAIBoGswGgYJKoZIhvcNAQkDMQOGCyqGSIb3 
DQEJEAEvMBWGCSqGSIb3DQEJBTEPFwOyMTA1MjAxN j IA4Mz 1aMC8GCSqGSIb3DQE 
JBDEiBCAr4vKeUvHJINsE0YQwUMxoo48qrOU-iPuFbQR8qXS3BF j ANBgkqhkiG9w 
@BAQEFAASCAQB85HSCBrU3EcVOcf4nC6Z3 j r0 j T-f VIyTDAObF6GTNWgrxe7 jSA 
Inyf51UzuIGqhVY3sQiiXbdWcVYtPb4118KvyeXh8A/HLp4eeAJnt19D3igt38M 
o84q5pf9pTQXx3hbsm51ilpOip/TKVMqzE42s60Pox3M0-*6eKH3 / vBKnw1s1ayM 
0MUnPDTBfZL3JJEGPWfIZHEcrypevbqR7Jjsz5vpOqyF2D9v-w*nyhZOPmuePm7 
YqLyOw/E99PVBs9uI-hmBiCz/BK2Z3VRjrrlrUU*49eldSTkZ2sJyhCbbV2Ufgi 
S2FOquAgJzjilyN3BDQLV8Rp9cGh@PpVs1KH2na 

End Signature: 192.0.2.0 - 192.0.2.255 
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